Computers, including personal computers, perform their functions by processing instructions, in the form of binary numbers, which can be interpreted by the central processing unit (CPU) of the machine. Programs written in assembly language use these instructions in a form that is easier for programmers to work with than binary numbers, and the resulting code is "assembled" into machine language for use by the computer. Programs written in higher level languages are "compiled" into machine language, and in this way, many different programs written in different languages can run on one machine. It was recognized early in the development of computer technology that many programs would require or could benefit from a common set of services, such as routines for handling input and output, managing files, interfacing with the user, and in some circumstances, multitasking two or more programs. These and other services are commonly provided by an operating system (e.g. DOS) or an operating environment acting in cooperation with an operating system. An important function of an operating system or environment is to manage resources available to or in use by programs running on the computer. In this context, a resource is any data object allocated to or from a limited memory space designated for use by the operating system or environment.
The Microsoft Windows.RTM. operating environment has a history of greater than ten years. It was originally designed to run on the Intel 8088 and 80286 microprocessors, both of which are 16-bit microprocessors. By way of background, the largest number representable with 16 binary bits is 65,536, and hence the largest amount of memory that is directly addressable at one time by a 16 bit operand is 64K (64.times.1024, or 65,536). As a consequence of the design of the processors, although more memory is available to these microprocessors through a segment-mapping concept, all system memory used in a computer utilizing an 8088 or 80286 microprocessor is divided into 64K chunks known as segments.
Although version 3 of Microsoft Windows.RTM. is optimized to use certain features of the Intel 80386 microprocessor (and later processors), if available, the original memory scheme was carried over, largely for compatibility reasons. Other processing and addressing modes are also available in these newer processors, most notably protected mode, which can handle 16 and 32 bit programs, and permits direct addressing of up to 4 GB of memory. In the version 3 releases of Windows, the primary modules of the operating environment continue to be 16-bit programs, although the 80386, 80486, and Pentium processors can accommodate 32-bit programs.
The three primary modules of Windows.RTM. 3.1 are KERNEL, which provides the lowest level of services to application programs; USER, which implements the windowed multitasking user interface; and GDI (Graphics Device Interface), which implements a device-independent methodology for displaying graphics on a screen or printer.
The USER module maintains its data in four 64K segments: the Window segment, the Menu segment, the Menu Atom (or Menu String) segment, and the Global Atom (or USER Atom) segment. The Window segment contains a variety of data defining window classes and characteristics. The Window segment is also the default data segment for the USER module, and as a result tends to contain a wide assortment of data. When the USER module requires temporary data space to perform an operation, it frequently allocates such space out of the Window segment. The Menu and Menu Atom segments are reserved specifically to hold data pertaining to drop-down menus, which are maintained by USER on behalf of the application programs that use them. The Global Atom segment exclusively contains alphanumeric strings registered by applications; it rarely contributes to resource shortages.
The GDI module maintains its data in two 64K segments: the GDI Object segment and the GDI Atom segment. The GDI Object segment contains information on pens, brushes, fonts, device contexts, and other items contained in data structures which can frequently be relatively large. The GDI Atom segment contains only font names; since it holds only a small amount of information, it rarely contributes to Windows.RTM. resource shortages.
While the amount of available physical memory on computers running Windows.RTM. has increased dramatically over the years, from 2M or 4M several years ago to 16M and higher today, and the sophistication of Windows.RTM. applications has also increased, the size of the data areas maintained by USER and GDI has remained constant. Thus, as systems have been experiencing higher and higher demand for resources, the availability of resources has begun to become more and more scarce.
The resource shortage problem has been recognized and solutions have been proposed. The product WinProbe by Quarterdeck (1994) attempts to solve the problem of GDI "resource leaks." WinProbe includes a component that tracks the task ownership of any GDI resources allocated by application programs. For this purpose it adds several bytes to the size of each such resource. Upon the user's direction or at a settable interval, WinProbe will attempt to clean up any resources that exist for tasks that are no longer running. This releases unused resources, but has several serious drawbacks. By increasing the size of each resource, WinProbe tends to aggravate resource shortages in one way while attempting to mitigate them in another way. Furthermore, resources cannot always safely or accurately be associated with the task context in which they were allocated. In Windows.RTM. 3.1, a library unassociated with the running task may allocate GDI resources; in such a case, it would be inappropriate and potentially unstable to free the resources at the time the task exits. Moreover certain resources may be allocated by a task and then placed into the system clipboard; these clipboard resources are required to remain allocated after the task has exited and it would be improper to free them. Finally, WinProbe requires user intervention or an elapsed time period before cleaning up unused resources.
Another prior art method for reducing GDI resource use is performed by the AnyView Professional product (Binar Graphics, 1994). AnyView relocates a certain class of object that GDI normally allocates in its own object segment into AnyView's own private memory. However, the objects that AnyView can deal with in this way are limited to objects for which GDI is custodian but does not need to access directly. This class includes primarily device-brush objects that are created by the display driver in memory allocated by GDI in the GDI Object segment and used only by the display driver. This solution does not sufficiently reduce resource load by itself.
The AnyView program also attempts to resolve resource scarcity by maintaining one of the system resource segments on a per-process basis. AnyView recognizes that the contents of the USER Menu segment represents a limited variety of data pertaining exclusively to drop-down menus, and that such data is primarily useful to the process that caused it to be created. Therefore, AnyView creates for each running application a separate copy of the USER Menu segment; the appropriate segment is activated whenever a different application is executed. AnyView's methodology is effective, but only for the USER Menu segment. It cannot be applied to the USER Window segment because that segment contains a large amount of data that cannot be associated with a single process; that data is required by USER to implement the windowing system. Moreover, though menus are typically accessed solely by their owning applications, they must be visible to other applications. This is mandated by specifications in the Microsoft Windows.RTM. Software Development Kit (SDK). Certain system libraries such as Object Linking and Embedding (OLE) rely on this property. Furthermore, an application may comprise multiple processes sharing a common user interface. These latter cases are not addressed by AnyView.
Another potential solution to the recognized limitations of 64K segment sizes can be implemented by relocating resource objects into 32-bit memory regions unconstrained by the 64K limit. This approach is realized by Microsoft Windows.RTM. 95, and was implemented in the "beta" releases of that product. However, this approach requires a significant rewrite of the USER and GDI modules, involving the modification of a great deal of original source code for Windows. Consequently, the approach is not feasible for a third-party improvement to the performance of an existing product, e.g., Windows.RTM. 3.1.
Windows.RTM. 95, including the beta releases, also associates GDI resources with the owning task. However, because of the possibility stated above that a resource was allocated by a library unassociated with the running task, Windows.RTM. 95 does not delete any unused GDI resources until no 16-bit applications are running. New 32-bit applications, written expressly for Windows.RTM. 95, do not have this limitation.
As shown above, the known methods for managing limited system resources have proven to be deficient in a number of ways. The invention addresses these deficiencies and improves resource management, particularly in cooperation with Microsoft Windows.RTM..